程式碼產出加快後，原本藏在流程中的等待也開始浮現。
過去團隊常將交付速度緩慢歸因於「開發還沒做完」，因為撰寫程式碼原先占用了大量時間。當 AI 縮短部分撰寫時間，團隊就會發現，許多工作其實是卡在產生程式碼前後的其他環節。
需求是否說明到位、驗收條件是否完整、設計是否完成確認、測試資料是否備妥、部署流程是否順利，這些問題一直存在，只是先前被較長的開發時間掩蓋。程式碼產出速度提高後，這些等待點便會浮上檯面。
AI 加速了價值流中的部分工作，也讓其他環節的排隊、等待與返工更早浮現。管理者與團隊可以藉此重新檢視整條交付流程，找出影響交付速度的限制。
當個人產出速度提高，瓶頸會移向團隊協作。
開發者可以更快產生程式碼，後續仍需要有人確認需求意圖、審查變更內容、執行測試、判斷風險，並決定何時可以上線。這些工作牽涉多個角色，單一成員無法獨立加速整個流程。
例如開發者透過 AI 很快完成功能雛形，產品負責人卻尚未確認例外流程。程式碼已經完成，拉取請求（Pull Request, PR）仍可能排在審查者手上兩天。測試案例已經備妥，測試環境與資料卻無法使用。工作會停在團隊交接點，無法實際完成交付。
價值流（Value Stream）關注的是需求如何從想法轉成使用者可以使用的成果。
只看個人是否忙碌，容易誤判實際交付狀態。開發者一天可以完成多個功能雛形，後續若缺少足夠的審查、測試與回饋能力，這些產出反而會形成新的等待隊列。
AI 提高個人工作速度後，團隊需要檢查協作能力是否足以承接新增產出。需求澄清、技術討論、程式碼審查、測試回饋與部署決策，都會直接影響整體流動速度。瓶頸位置改變時，改善工作也要移到新的限制點。
AI 加速開發後，團隊容易出現一種表面上的忙碌。開發者忙著產出與修改程式碼，審查者忙著閱讀大量變更，測試人員忙著整理測試案例與回報問題，產品角色則忙著補充需求細節。每個人手上都有工作，整體交付時間卻沒有同步縮短。
團隊需要分辨「人很忙」與「工作持續往前流動」。人很忙代表資源已被占用，工作往前流動則代表需求正穩定通過理解、開發、驗證與上線。
當一張工單長時間停在等待確認、等待審查、等待測試或等待部署，相關人員即使行程滿檔，使用者仍未取得成果。
忙碌也可能掩蓋排隊問題。當每個人同時處理多項工作，任務切換次數會增加，回覆速度會變慢，背景脈絡也可能流失。
某項功能今天被擱置，兩天後重新處理時，開發者與審查者都需要再次理解前因後果，原先短暫的等待便會轉成額外的理解成本。
觀察價值流時，團隊可以先檢查工作停留時間。哪些需求長時間尚未確認、哪些拉取請求排隊過久、哪些測試反覆等待資料、哪些上線決策一再延後，都能反映流程中的瓶頸。
一個需求被提出後，多半還不能直接進入開發。最初的需求描述可能只有業務目標、使用者抱怨、主管指示，或一句簡短的功能方向。
這些資訊可以說明想改善的問題，仍不足以讓開發者、測試人員與產品角色建立一致理解。
這個階段的等待多半發生在需求確認。團隊需要釐清使用者是誰、目前流程卡在哪裡、成功結果應呈現什麼狀態、需要處理哪些情境，以及哪些規則存在例外。
內容尚未確認時，AI 即使能快速產出功能草稿，程式邏輯仍可能建立在自行補充的假設上。
需求等待釐清期間，表面上可能看不出明顯的阻塞。產品角色正在補充資訊，開發者正在閱讀規格，測試人員正在整理測試情境，利害關係人也在等待確認。若開發開始後才發現各方理解不同，後續就需要返工、補充規格並重新測試。
AI 加快開發速度後，需求確認的等待會更早浮現。需求尚未說明完整，開發者已經能產出結構完整的功能。團隊需要先建立共同理解，再讓需求進入開發流程，才能避免模糊內容快速流向後段。
需求進入產品待辦清單（Product Backlog）後，仍需整理成團隊可以執行的工作。
待辦項目若只有一段需求描述，開發者還要判斷會影響哪些模組、需要調整哪些 API、資料如何處理、測試涵蓋哪些範圍，以及是否涉及部署流程或權限設定。
這個階段常出現另一個等待點：需求已經完成排序，工作內容仍未拆成可以開始處理的大小。
範圍過大時，開發者難以判斷第一步。工作邊界不清時，AI 產出的程式碼也可能一次跨越多個區域，增加後續理解與審查的負擔。
可執行的工作需要具備基本上下文、驗收條件與完成標準。團隊要知道工作完成後，使用者會增加哪些能力，測試人員如何確認結果正確，開發者需要遵守哪些業務規則與技術限制。
資訊整理到可執行的程度後，AI 輔助開發才能被控制在明確範圍內。
當產品待辦清單缺少拆解，開發速度提高會讓問題更快浮現。當多位開發者一起協力開發，同時透過 AI 產出不同部分，最後就可能發現工作邊界重疊、規則不一致、命名方式不同，資料假設也彼此衝突。
這些問題多半發生在工作尚未整理完整，就直接被推進實作階段。
功能完成後，工作仍需經過審查、測試與需求確認。程式碼需要進入程式碼審查，測試人員要確認系統行為是否符合預期，產品角色也要檢查功能是否符合需求意圖。產出速度提高後，這些環節容易形成新的等待隊列。
程式碼審查會先承受壓力。AI 產出的程式可能具備完整的命名、結構與測試，審查者仍需確認變更目的、業務規則、錯誤處理、安全風險與架構一致性。
當拉取請求數量增加，單次變更範圍又過大，審查工作就會開始排隊。
測試環節也會出現相同的等待。AI 可以協助產生測試草稿，測試資料、測試環境、整合驗證與例外情境仍需由團隊準備。
測試環境不穩定、資料建立困難或外部系統無法配合，都會讓完成功能停在等待驗證。
回饋延遲會增加修正成本。開發者剛完成開發時，仍掌握程式脈絡。隔了數天才收到審查意見或測試結果，就需要重新閱讀規格、理解程式並恢復原先思路。
團隊需要縮短審查、測試與回饋的等待，讓問題在脈絡還完整時被發現與處理。
功能通過驗證後，仍需進入部署與上線流程。這個階段容易被忽略，因為團隊常將「開發完成」視為主要成果。
對使用者而言，尚未上線的功能還無法產生價值。需求要走到交付終點，部署流程、環境準備、監控、回退方案與上線決策都需要順利銜接。
等待部署可能來自技術流程。環境需要排程、資料庫變更需要審查、設定檔需要確認、CI/CD 管線需要修復，維運人員也要知道上線後應觀察哪些狀態。
這些條件若沒有提前準備，功能即使通過測試，仍會停在等待部署。
上線決策也是常見的等待點。產品角色、業務單位、客服、維運與管理者都可能需要確認發布時機。功能若會影響他們的日常業務，上線前就需要確認相關準備。決策責任模糊時，功能就會停在「已完成尚未釋出」的狀態。
開發速度提高後，部署與上線階段的等待會更早暴露。團隊可能在一週內完成多項功能，最後全部排在部署窗口、上線審核或跨部門確認之前。價值流中任何一段等待，都會延後使用者取得成果的時間。
在製品（Work in Progress, WIP）代表團隊同時開始、尚未完成的工作數量。
程式碼產出速度提高後，在製品容易跟著增加。每位成員手上都有多張需求單，每張單都完成了一部分，整體看起來十分忙碌，真正完成並交到使用者手上的項目卻不多。
在製品過高時，價值流會開始排隊。開發者完成開發後，工作等待程式碼審查。審查結束後，工作等待測試。測試完成後，工作又等待部署。每個環節都堆著多件待處理項目，單一工作從開始到完成的時間也會被拉長。
AI 會進一步放大這個現象。過去開發者產出速度較慢，後段的審查與測試還有時間消化。現在前段產出增加，後段處理能力若沒有同步提升，等待隊列就會變長。這反映的是整個系統同時承接了過多工作。
控制在製品的重點，是讓團隊集中完成已經開始的工作。當在製品數量受到限制，正在排隊的環節就會浮現，團隊也需要調整人力，優先處理瓶頸，避免工作繼續堆積。
插單是臨時加入原定計畫之外的工作，來源可能是客戶要求、主管指示、正式環境問題、法規調整或臨時商業機會。
有些事項確實需要優先處理。當團隊缺少明確的插單規則，既有工作節奏就會受到影響。
插單進入流程後，團隊需要重新分配注意力。開發者會暫停手上的工作，重新理解新需求。審查者需要調整審查順序。測試人員必須更改測試安排。產品角色也要重新確認優先順序。
原先進行中的工作因此停下，新工作也要進入需求確認、開發、審查與測試，整條價值流便會失去穩定節奏。
開發速度變快後，插單看起來較容易被接受。團隊可能認為臨時增加一項功能不會造成太大影響，後續卻會出現其他成本。原有功能延後審查、測試排程被打散、上線範圍變得模糊，需求背景也可能在頻繁切換中遺漏。
處理插單需要明確的入口與判斷方式。團隊可以先確認工作是否急迫、會影響哪些既有項目、是否需要移出其他工作，以及由誰決定優先順序。
插單被納入正式的價值流管理後，團隊才能看見它造成的範圍變動與等待成本。
需求在流程中等待越久，團隊對需求的理解就越容易流失。剛完成討論時，成員對使用情境、例外規則、限制條件與取捨原因仍有具體印象。
工作卡若長時間停在等待程式碼審查、等待測試或等待部署，幾天後重新處理時，團隊就需要額外花時間找回上下文。
AI 加快開發速度後，這個問題會更快浮現。功能初稿可以在短時間內完成，後續工作卻可能排在其他項目之後。審查者開始審查時，開發者已經記不清當初的設計理由。測試人員開始測試時，產品角色也需要重新說明需求細節。日曆上的等待空檔，會轉成重新閱讀、追問與理解的成本。
交接也會增加脈絡流失。需求從產品角色交給開發者，再從開發者交給審查者、測試人員、維運與使用者支援。每次交接若只留下處理結果，缺少背景與判斷依據，後續接手者只能從文件、程式碼與零散訊息中重新拼湊原因。
減少等待與交接成本，需要讓重要脈絡留在工作流程中。需求說明、驗收條件、設計取捨、AI 使用紀錄、測試結果與上線注意事項，都應跟著工作項目一起移動。如此即使工作暫時停留，重新接手時也能快速找回背景。
開發速度變快後，團隊更需要控制每次交付的範圍。批次過大時，需求、設計、程式碼、測試與部署變更會混在一起。等到程式碼審查或測試階段才發現問題，就需要重新閱讀大量內容，修正範圍與成本也會增加。
小批次是將工作切成容易理解、可以獨立驗證的單位。每一批變更都要有明確目的，例如先完成一段 API 行為、先處理一個使用情境，或先驗證一項資料規則。範圍明確後，審查者能快速掌握變更意圖，測試人員也能提早建立測試與回饋。
AI 適合協助產生初稿，團隊仍需控制每次接受與處理的內容量。一次產生整個模組、完整流程或大量測試，會增加後續閱讀與審查負擔。限制 AI 產出小段成果，逐段確認設計、實作與測試，可以讓問題提早被發現。
小批次也能讓產品角色更快參與確認。功能先以小範圍成形後，產品角色可以檢查流程是否符合需求意圖，使用者也能提早看到可討論的成果。方向錯誤時，修正範圍也比較小。
限制在製品是改善價值流的重要方法。當團隊同時處理過多工作，每個人都會維持忙碌，工作也容易停在不同階段。
設定在製品限制，可以讓團隊先完成已經開始的工作，再拉入新的項目。
在製品限制能讓瓶頸浮現。開發欄位很快清空，審查欄位卻堆滿工作，代表審查能力不足。測試欄位長時間塞住，團隊就需要檢查測試資料、測試環境與人力安排。部署前出現排隊時，發布流程、操作權限與決策機制也要被檢查。
AI 會放大在製品問題。開發者可以更快把工作推到下一個階段，下游缺少足夠處理能力時，等待就會集中在後段流程。
此時若繼續要求開發者增加程式碼產出，隊列會變得更長，審查與測試也會承受更多壓力。
限制在製品能促使團隊共同處理阻塞。當某個階段達到上限，成員可以先協助程式碼審查、準備測試資料、釐清需求或處理部署問題。團隊的注意力會從完成個人任務，轉向讓整體工作順利交付。
看板（Kanban Board）可以讓團隊看見工作目前停留的位置。對 AI 時代的開發團隊而言，看板除了管理任務，也能呈現需求從提出到上線的流動狀態。
每張卡片所在的欄位，代表工作正在等待釐清、開發、審查、測試、部署，或已經完成交付。
看板的價值來自工作狀態透明。當進度只存在個人記憶或聊天訊息中，其他成員很難掌握阻塞原因。
團隊將狀態放進共同看板後，就能直接討論哪些卡片停留過久、哪些欄位累積太多工作，以及哪些項目缺少明確的下一步。
AI 增加產出量後，工作資訊也需要完整保留。團隊要知道哪些工作使用了 AI、哪些變更需要提高審查強度、哪些內容尚未驗證，以及哪些需求仍有待確認事項。
資訊若未跟著工作卡移動，後續接手者就要重新追問與整理。
看板可以先從簡單流程開始。入門團隊可設定「待釐清、待開發、開發中、待審查、待測試、待部署、完成」等欄位。團隊先透過看板掌握工作停留位置，再依實際阻塞調整欄位、在製品限制與流動規則，讓看板反映真正的交付流程。
價值流映射（Value Stream Mapping, VSM）是一種觀察工作流動的方法。團隊會畫出需求從提出到上線的主要步驟，並標示各階段的處理時間、等待時間、常見返工，以及需要排隊的決策。這些資訊能協助團隊從完整路徑理解交付問題。
價值流映射可以把注意力拉回完整交付路徑。程式碼生成速度提高，整體交付時間仍可能維持不變。透過映射，團隊可以看見需求等待確認花了幾天、拉取請求排隊多久、測試資料準備需要多少時間，以及部署決策停在哪個角色手上。
返工也需要標示在價值流中。同類需求經常在測試後退回開發，可能代表驗收條件或完成定義（Definition of Done, DoD）不夠明確。功能經常在上線前被退回，則需要檢查部署準備、維運資訊與利害關係人確認是否完整。
返工會占用開發、審查與測試能力，抵銷 AI 提高產出速度所節省的時間。
價值流映射能為改善工作提供具體起點。團隊可以先找出等待最久、返工最多或影響範圍最大的環節，再決定改善順序。
當團隊找出最大卡點後，小批次、在製品限制、看板透明化與流程調整才能對準具體問題。
iThome鐵人賽
看影片追技術